in a Cobol program, how would you determine/check if enscribe file is open?
I used COBOLFILEINFO and OPENINFO but it does not seem to return the proper code if a file is opened by another process. Any hint will be highly appreciated.

On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> in a Cobol program, how would you determine/check if enscribe file is open?
> I used COBOLFILEINFO and OPENINFO but it does not seem to return the proper code if a file is opened by another process. Any hint will be highly appreciated.

COBOLFILEINFO definitely won't do what you want. OPENINFO might let you determine whether the file is open, but the description in the manual is not clear about which of the values it will return when a file is not open, so I would not depend on it.

I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBYNAME_ and request the value of item 75.

As far as I can see from looking at the documentation of that procedure, you should be able to call it from COBOL, but you must be careful to set up the item list argument and the result argument to be binary values of the correct size. Also, I believe that when calling from COBOL, you pass just the name of the PIC X(n) data item that contains the file name and don't pass anything for the length (at least at one time, COBOL would determine the length itself and pass it automatically, without the programmer explicitly putting it into the call).

If you cannot figure out how to make COBOL call that procedure, it might be easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_ call (assuming you know C and are not familiar with TAL) and have the C function return the value of item 75 for your COBOL code to check.

On Wednesday, June 16, 2021 at 10:24:35 PM UTC-4, abol...@gmail.com wrote:
> in a Cobol program, how would you determine/check if enscribe file is open?
> I used COBOLFILEINFO and OPENINFO but it does not seem to return the proper code if a file is opened by another process. Any hint will be highly appreciated.

If you need to open the file anyway and you don't care who might have it open, why not just handle the error you would get?

I haven't coded COBOL in ages but looking at an old program, we would check for file status of 30 and the GUARDIAN-ERR special register (if such a thing still exists) of 12.

In article <03138bc6-de93-49d1-97ef-236cd475a9b5n@googlegroups.com>,
rkdick@gmail.com says...
>
>On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
>> in a Cobol program, how would you determine/check if enscribe file is ope=
>n?=20
>> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
>er code if a file is opened by another process. Any hint will be highly app=
>reciated.
>
>COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
>termine whether the file is open, but the description in the manual is not =
>clear about which of the values it will return when a file is not open, so =
>I would not depend on it.
>
>I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
>NAME_ and request the value of item 75.
>
>As far as I can see from looking at the documentation of that procedure, yo=
>u should be able to call it from COBOL, but you must be careful to set up t=
>he item list argument and the result argument to be binary values of the co=
>rrect size. Also, I believe that when calling from COBOL, you pass just th=
>e name of the PIC X(n) data item that contains the file name and don't pass=
> anything for the length (at least at one time, COBOL would determine the l=
>ength itself and pass it automatically, without the programmer explicitly p=
>utting it into the call).
>
>If you cannot figure out how to make COBOL call that procedure, it might be=
> easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> call (assuming you know C and are not familiar with TAL) and have the C fu=
>nction return the value of item 75 for your COBOL code to check.

Additionally

The FILE_GETOPENINFO_ procedure obtains information about the
opens of one disk file or all the files on a disk device
or the opens of certain nondisk devices.

Each call returns information about one open;
make successive calls to FILE_GETOPENINFO_ to learn about
all the opens.

On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> In article <03138bc6-de93-49d1...@googlegroups.com>,
> rkd...@gmail.com says...
> >
> >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> >> in a Cobol program, how would you determine/check if enscribe file is ope=
> >n?=20
> >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> >er code if a file is opened by another process. Any hint will be highly app=
> >reciated.
> >
> >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> >termine whether the file is open, but the description in the manual is not =
> >clear about which of the values it will return when a file is not open, so =
> >I would not depend on it.
> >
> >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> >NAME_ and request the value of item 75.
> >
> >As far as I can see from looking at the documentation of that procedure, yo=
> >u should be able to call it from COBOL, but you must be careful to set up t=
> >he item list argument and the result argument to be binary values of the co=
> >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> >e name of the PIC X(n) data item that contains the file name and don't pass=
> > anything for the length (at least at one time, COBOL would determine the l=
> >ength itself and pass it automatically, without the programmer explicitly p=
> >utting it into the call).
> >
> >If you cannot figure out how to make COBOL call that procedure, it might be=
> > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > call (assuming you know C and are not familiar with TAL) and have the C fu=
> >nction return the value of item 75 for your COBOL code to check.
> Additionally
>
> The FILE_GETOPENINFO_ procedure obtains information about the
> opens of one disk file or all the files on a disk device
> or the opens of certain nondisk devices.
>
> Each call returns information about one open;
> make successive calls to FILE_GETOPENINFO_ to learn about
> all the opens.

Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:

In working storage:

01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
01 WS-FILE-GETINFOLIST.
05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
05 WS-FGIL-ITEM-LIST.
10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
05 WS-FGIL-ITEM-VALUES.
10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
88 NOT-AN-SQL-OBJECT VALUE 0.
10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
88 FILE-IS-UNSTRUCTURED VALUE 0.
10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
88 FILE-IS-TYPE-101 VALUE 101.
10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
88 FILE-IS-NOT-OPEN VALUE 0.
88 FILE-IS-OPEN VALUE 1.
88 FILE-NOT-FOUND VALUE 11.
88 FILE-IS-A-KEEPER VALUE ZERO.
88 FILE-IS-NOT-A-KEEPER VALUE 99.
10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.

in code:

**** populate the file name and file name length fields first ***

ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
, WS-FGIL-ITEM-LIST
, WS-FGIL-ITEM-COUNT
, WS-FGIL-ITEM-VALUES
, WS-FGIL-ITEM-VALUES-LEN
GIVING WS-PROC-CALL-STATUS.

**** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.

On Thursday, June 17, 2021 at 12:42:34 PM UTC-7, Rich S. wrote:
> On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> > In article <03138bc6-de93-49d1...@googlegroups.com>,
> > rkd...@gmail.com says...
> > >
> > >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > >> in a Cobol program, how would you determine/check if enscribe file is ope=
> > >n?=20
> > >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> > >er code if a file is opened by another process. Any hint will be highly app=
> > >reciated.
> > >
> > >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> > >termine whether the file is open, but the description in the manual is not =
> > >clear about which of the values it will return when a file is not open, so =
> > >I would not depend on it.
> > >
> > >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> > >NAME_ and request the value of item 75.
> > >
> > >As far as I can see from looking at the documentation of that procedure, yo=
> > >u should be able to call it from COBOL, but you must be careful to set up t=
> > >he item list argument and the result argument to be binary values of the co=
> > >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> > >e name of the PIC X(n) data item that contains the file name and don't pass=
> > > anything for the length (at least at one time, COBOL would determine the l=
> > >ength itself and pass it automatically, without the programmer explicitly p=
> > >utting it into the call).
> > >
> > >If you cannot figure out how to make COBOL call that procedure, it might be=
> > > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > > call (assuming you know C and are not familiar with TAL) and have the C fu=
> > >nction return the value of item 75 for your COBOL code to check.
> > Additionally
> >
> > The FILE_GETOPENINFO_ procedure obtains information about the
> > opens of one disk file or all the files on a disk device
> > or the opens of certain nondisk devices.
> >
> > Each call returns information about one open;
> > make successive calls to FILE_GETOPENINFO_ to learn about
> > all the opens.
> Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:
>
> In working storage:
>
> 01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
> 01 WS-FILE-GETINFOLIST.
> 05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
> 05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
> 05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
> 05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
> 05 WS-FGIL-ITEM-LIST.
> 10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
> 10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
> 10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
> 10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
> 10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
> 05 WS-FGIL-ITEM-VALUES.
> 10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
> 88 NOT-AN-SQL-OBJECT VALUE 0.
> 10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
> 88 FILE-IS-UNSTRUCTURED VALUE 0.
> 10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
> 88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
> 88 FILE-IS-TYPE-101 VALUE 101.
> 10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
> 88 FILE-IS-NOT-OPEN VALUE 0.
> 88 FILE-IS-OPEN VALUE 1.
> 88 FILE-NOT-FOUND VALUE 11.
> 88 FILE-IS-A-KEEPER VALUE ZERO.
> 88 FILE-IS-NOT-A-KEEPER VALUE 99.
> 10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.
>
> in code:
>
> **** populate the file name and file name length fields first ***
>
> ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
> , WS-FGIL-ITEM-LIST
> , WS-FGIL-ITEM-COUNT
> , WS-FGIL-ITEM-VALUES
> , WS-FGIL-ITEM-VALUES-LEN
> GIVING WS-PROC-CALL-STATUS.
>
> **** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.

OMG, It worked! Thank you so much, been trying for couple of days. You're DA Best!

On Wednesday, June 16, 2021 at 9:52:05 PM UTC-7, rkd...@gmail.com wrote:
> On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > in a Cobol program, how would you determine/check if enscribe file is open?
> > I used COBOLFILEINFO and OPENINFO but it does not seem to return the proper code if a file is opened by another process. Any hint will be highly appreciated.
> COBOLFILEINFO definitely won't do what you want. OPENINFO might let you determine whether the file is open, but the description in the manual is not clear about which of the values it will return when a file is not open, so I would not depend on it.
>
> I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBYNAME_ and request the value of item 75.
>
> As far as I can see from looking at the documentation of that procedure, you should be able to call it from COBOL, but you must be careful to set up the item list argument and the result argument to be binary values of the correct size. Also, I believe that when calling from COBOL, you pass just the name of the PIC X(n) data item that contains the file name and don't pass anything for the length (at least at one time, COBOL would determine the length itself and pass it automatically, without the programmer explicitly putting it into the call).
>
> If you cannot figure out how to make COBOL call that procedure, it might be easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_ call (assuming you know C and are not familiar with TAL) and have the C function return the value of item 75 for your COBOL code to check.

Many thanks! You put me on the right track. I appreciate your help!

On Thursday, June 17, 2021 at 12:42:34 PM UTC-7, Rich S. wrote:
> On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> > In article <03138bc6-de93-49d1...@googlegroups.com>,
> > rkd...@gmail.com says...
> > >
> > >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > >> in a Cobol program, how would you determine/check if enscribe file is ope=
> > >n?=20
> > >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> > >er code if a file is opened by another process. Any hint will be highly app=
> > >reciated.
> > >
> > >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> > >termine whether the file is open, but the description in the manual is not =
> > >clear about which of the values it will return when a file is not open, so =
> > >I would not depend on it.
> > >
> > >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> > >NAME_ and request the value of item 75.
> > >
> > >As far as I can see from looking at the documentation of that procedure, yo=
> > >u should be able to call it from COBOL, but you must be careful to set up t=
> > >he item list argument and the result argument to be binary values of the co=
> > >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> > >e name of the PIC X(n) data item that contains the file name and don't pass=
> > > anything for the length (at least at one time, COBOL would determine the l=
> > >ength itself and pass it automatically, without the programmer explicitly p=
> > >utting it into the call).
> > >
> > >If you cannot figure out how to make COBOL call that procedure, it might be=
> > > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > > call (assuming you know C and are not familiar with TAL) and have the C fu=
> > >nction return the value of item 75 for your COBOL code to check.
> > Additionally
> >
> > The FILE_GETOPENINFO_ procedure obtains information about the
> > opens of one disk file or all the files on a disk device
> > or the opens of certain nondisk devices.
> >
> > Each call returns information about one open;
> > make successive calls to FILE_GETOPENINFO_ to learn about
> > all the opens.
> Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:
>
> In working storage:
>
> 01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
> 01 WS-FILE-GETINFOLIST.
> 05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
> 05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
> 05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
> 05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
> 05 WS-FGIL-ITEM-LIST.
> 10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
> 10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
> 10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
> 10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
> 10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
> 05 WS-FGIL-ITEM-VALUES.
> 10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
> 88 NOT-AN-SQL-OBJECT VALUE 0.
> 10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
> 88 FILE-IS-UNSTRUCTURED VALUE 0.
> 10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
> 88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
> 88 FILE-IS-TYPE-101 VALUE 101.
> 10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
> 88 FILE-IS-NOT-OPEN VALUE 0.
> 88 FILE-IS-OPEN VALUE 1.
> 88 FILE-NOT-FOUND VALUE 11.
> 88 FILE-IS-A-KEEPER VALUE ZERO.
> 88 FILE-IS-NOT-A-KEEPER VALUE 99.
> 10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.
>
> in code:
>
> **** populate the file name and file name length fields first ***
>
> ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
> , WS-FGIL-ITEM-LIST
> , WS-FGIL-ITEM-COUNT
> , WS-FGIL-ITEM-VALUES
> , WS-FGIL-ITEM-VALUES-LEN
> GIVING WS-PROC-CALL-STATUS.
>
> **** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.
Would you please post a link to the document where item number codes and its usage can be located. I guess how did you know item number 75 will return file open status? what would be the item number to determine security violation (AKA Error 48) if a process is trying yo open a file that is secured "UUUU" . Thanks in advance.

On Saturday, August 14, 2021 at 6:51:49 PM UTC-7, abol...@gmail.com wrote:
> On Thursday, June 17, 2021 at 12:42:34 PM UTC-7, Rich S. wrote:
> > On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> > > In article <03138bc6-de93-49d1...@googlegroups.com>,
> > > rkd...@gmail.com says...
> > > >
> > > >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > > >> in a Cobol program, how would you determine/check if enscribe file is ope=
> > > >n?=20
> > > >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> > > >er code if a file is opened by another process. Any hint will be highly app=
> > > >reciated.
> > > >
> > > >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> > > >termine whether the file is open, but the description in the manual is not =
> > > >clear about which of the values it will return when a file is not open, so =
> > > >I would not depend on it.
> > > >
> > > >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> > > >NAME_ and request the value of item 75.
> > > >
> > > >As far as I can see from looking at the documentation of that procedure, yo=
> > > >u should be able to call it from COBOL, but you must be careful to set up t=
> > > >he item list argument and the result argument to be binary values of the co=
> > > >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> > > >e name of the PIC X(n) data item that contains the file name and don't pass=
> > > > anything for the length (at least at one time, COBOL would determine the l=
> > > >ength itself and pass it automatically, without the programmer explicitly p=
> > > >utting it into the call).
> > > >
> > > >If you cannot figure out how to make COBOL call that procedure, it might be=
> > > > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > > > call (assuming you know C and are not familiar with TAL) and have the C fu=
> > > >nction return the value of item 75 for your COBOL code to check.
> > > Additionally
> > >
> > > The FILE_GETOPENINFO_ procedure obtains information about the
> > > opens of one disk file or all the files on a disk device
> > > or the opens of certain nondisk devices.
> > >
> > > Each call returns information about one open;
> > > make successive calls to FILE_GETOPENINFO_ to learn about
> > > all the opens.
> > Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:
> >
> > In working storage:
> >
> > 01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
> > 01 WS-FILE-GETINFOLIST.
> > 05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
> > 05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
> > 05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
> > 05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
> > 05 WS-FGIL-ITEM-LIST.
> > 10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
> > 10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
> > 10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
> > 10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
> > 10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
> > 05 WS-FGIL-ITEM-VALUES.
> > 10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
> > 88 NOT-AN-SQL-OBJECT VALUE 0.
> > 10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
> > 88 FILE-IS-UNSTRUCTURED VALUE 0.
> > 10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
> > 88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
> > 88 FILE-IS-TYPE-101 VALUE 101.
> > 10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
> > 88 FILE-IS-NOT-OPEN VALUE 0.
> > 88 FILE-IS-OPEN VALUE 1.
> > 88 FILE-NOT-FOUND VALUE 11.
> > 88 FILE-IS-A-KEEPER VALUE ZERO.
> > 88 FILE-IS-NOT-A-KEEPER VALUE 99.
> > 10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.
> >
> > in code:
> >
> > **** populate the file name and file name length fields first ***
> >
> > ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
> > , WS-FGIL-ITEM-LIST
> > , WS-FGIL-ITEM-COUNT
> > , WS-FGIL-ITEM-VALUES
> > , WS-FGIL-ITEM-VALUES-LEN
> > GIVING WS-PROC-CALL-STATUS.
> >
> > **** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.
> Would you please post a link to the document where item number codes and its usage can be located. I guess how did you know item number 75 will return file open status? what would be the item number to determine security violation (AKA Error 48) if a process is trying yo open a file that is secured "UUUU" . Thanks in advance.

Although your post is dated June 17, it only appeared in the Google Groups version of comp.sys.tandem today, August 14. I don't know why there was such a delay.

You can access the HPE documentation for the NonStop systems by:

1. Go to www.hpe.com/info/nonstop-docs
2. Click the link for your type of NonStop system ( L-series, J-series, or H-series)
3. On the next page, click on the heading "Manuals and Guides"
4. That will open a search terms entry box into which you can enter terms to search the documentation library.
5. If you know the title of the document you want, you can enter the full or partial title then end with
the Enter key, and that usually will get the search to find the document.
You can instead enter terms to search for, and the search will list documents that contain
the terms.
6. When you see a document you want in the search results, click on the title, and that will
open the document (a PDF file) in a new tab or new window. You can read the manual in
that new window or you can download the PDF file to your computer by clicking on the icon that
is a down pointing arrow that appears at the top right corner of the area in which the document
is displayed. I usually find it a lot easier to navigate the document after downloading it.

The title of the manual that contains the description of FILE_GETINFOLISTBYNAME_ is:

Guardian Procedure Calls Reference Manual

Entering "guardian proc calls" in the search terms usually is good enough to find it. You could also type
the procedure name as the search terms and find the same manual.

If you don't know the name of the manual and don't now which procedure you need to use, then you have
a harder problem. Sometimes you'll be able to think of search terms that will allow you to find a manual
that will answer your question, but often, you'll have to ask someone for a pointer in the right direction.

Someone at HPE keeps fiddling with the documentation library, so the next time you try to use it, you might find the navigation to the search page is somewhat different, but usually, you'll be able to figure out how to get there.

On Saturday, August 14, 2021 at 6:51:49 PM UTC-7, abol...@gmail.com wrote:
> On Thursday, June 17, 2021 at 12:42:34 PM UTC-7, Rich S. wrote:
> > On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> > > In article <03138bc6-de93-49d1...@googlegroups.com>,
> > > rkd...@gmail.com says...
> > > >
> > > >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > > >> in a Cobol program, how would you determine/check if enscribe file is ope=
> > > >n?=20
> > > >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> > > >er code if a file is opened by another process. Any hint will be highly app=
> > > >reciated.
> > > >
> > > >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> > > >termine whether the file is open, but the description in the manual is not =
> > > >clear about which of the values it will return when a file is not open, so =
> > > >I would not depend on it.
> > > >
> > > >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> > > >NAME_ and request the value of item 75.
> > > >
> > > >As far as I can see from looking at the documentation of that procedure, yo=
> > > >u should be able to call it from COBOL, but you must be careful to set up t=
> > > >he item list argument and the result argument to be binary values of the co=
> > > >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> > > >e name of the PIC X(n) data item that contains the file name and don't pass=
> > > > anything for the length (at least at one time, COBOL would determine the l=
> > > >ength itself and pass it automatically, without the programmer explicitly p=
> > > >utting it into the call).
> > > >
> > > >If you cannot figure out how to make COBOL call that procedure, it might be=
> > > > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > > > call (assuming you know C and are not familiar with TAL) and have the C fu=
> > > >nction return the value of item 75 for your COBOL code to check.
> > > Additionally
> > >
> > > The FILE_GETOPENINFO_ procedure obtains information about the
> > > opens of one disk file or all the files on a disk device
> > > or the opens of certain nondisk devices.
> > >
> > > Each call returns information about one open;
> > > make successive calls to FILE_GETOPENINFO_ to learn about
> > > all the opens.
> > Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:
> >
> > In working storage:
> >
> > 01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
> > 01 WS-FILE-GETINFOLIST.
> > 05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
> > 05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
> > 05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
> > 05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
> > 05 WS-FGIL-ITEM-LIST.
> > 10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
> > 10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
> > 10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
> > 10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
> > 10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
> > 05 WS-FGIL-ITEM-VALUES.
> > 10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
> > 88 NOT-AN-SQL-OBJECT VALUE 0.
> > 10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
> > 88 FILE-IS-UNSTRUCTURED VALUE 0.
> > 10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
> > 88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
> > 88 FILE-IS-TYPE-101 VALUE 101.
> > 10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
> > 88 FILE-IS-NOT-OPEN VALUE 0.
> > 88 FILE-IS-OPEN VALUE 1.
> > 88 FILE-NOT-FOUND VALUE 11.
> > 88 FILE-IS-A-KEEPER VALUE ZERO.
> > 88 FILE-IS-NOT-A-KEEPER VALUE 99.
> > 10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.
> >
> > in code:
> >
> > **** populate the file name and file name length fields first ***
> >
> > ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
> > , WS-FGIL-ITEM-LIST
> > , WS-FGIL-ITEM-COUNT
> > , WS-FGIL-ITEM-VALUES
> > , WS-FGIL-ITEM-VALUES-LEN
> > GIVING WS-PROC-CALL-STATUS.
> >
> > **** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.
> Would you please post a link to the document where item number codes and its usage can be located. I guess how did you know item number 75 will return file open status? what would be the item number to determine security violation (AKA Error 48) if a process is trying yo open a file that is secured "UUUU" . Thanks in advance.

I'm not quite sure what the second part of your question is asking for. If you want to know the item code that shows the file security setting, that is given by item 62, but you probably also would have to look at item 58, which tells you the userid of the file owner, and item 59, which tells you whether the file is under Safeguard security or not.

Only the process that tried to open a file will get the error 48, so I'm not sure what that part of the question is about. The FILE_OPEN_ call that got the error 48 will have 48 returned from the call. If the older OPEN procedure was used to try to open the file, you'd get the error number using the FILEINFO procedure. As far as I recall, there is no way for one process to tell what file error another process got, except maybe using the procedures intended to implement debuggers, which I'm not familiar with. I have a feeling that is not what you are asking about, anyway.

On Saturday, August 14, 2021 at 10:50:22 PM UTC-7, rkd...@gmail.com wrote:
> On Saturday, August 14, 2021 at 6:51:49 PM UTC-7, abol...@gmail.com wrote:
> > On Thursday, June 17, 2021 at 12:42:34 PM UTC-7, Rich S. wrote:
> > > On Thursday, June 17, 2021 at 3:15:21 PM UTC-4, JShepherd wrote:
> > > > In article <03138bc6-de93-49d1...@googlegroups.com>,
> > > > rkd...@gmail.com says...
> > > > >
> > > > >On Wednesday, June 16, 2021 at 7:24:35 PM UTC-7, abol...@gmail.com wrote:
> > > > >> in a Cobol program, how would you determine/check if enscribe file is ope=
> > > > >n?=20
> > > > >> I used COBOLFILEINFO and OPENINFO but it does not seem to return the prop=
> > > > >er code if a file is opened by another process. Any hint will be highly app=
> > > > >reciated.
> > > > >
> > > > >COBOLFILEINFO definitely won't do what you want. OPENINFO might let you de=
> > > > >termine whether the file is open, but the description in the manual is not =
> > > > >clear about which of the values it will return when a file is not open, so =
> > > > >I would not depend on it.
> > > > >
> > > > >I believe you must make a call to the Guardian procedure FILE_GETINFOLISTBY=
> > > > >NAME_ and request the value of item 75.
> > > > >
> > > > >As far as I can see from looking at the documentation of that procedure, yo=
> > > > >u should be able to call it from COBOL, but you must be careful to set up t=
> > > > >he item list argument and the result argument to be binary values of the co=
> > > > >rrect size. Also, I believe that when calling from COBOL, you pass just th=
> > > > >e name of the PIC X(n) data item that contains the file name and don't pass=
> > > > > anything for the length (at least at one time, COBOL would determine the l=
> > > > >ength itself and pass it automatically, without the programmer explicitly p=
> > > > >utting it into the call).
> > > > >
> > > > >If you cannot figure out how to make COBOL call that procedure, it might be=
> > > > > easier for you to write a C function that does the FILE_GETINFOLISTBYNAME_=
> > > > > call (assuming you know C and are not familiar with TAL) and have the C fu=
> > > > >nction return the value of item 75 for your COBOL code to check.
> > > > Additionally
> > > >
> > > > The FILE_GETOPENINFO_ procedure obtains information about the
> > > > opens of one disk file or all the files on a disk device
> > > > or the opens of certain nondisk devices.
> > > >
> > > > Each call returns information about one open;
> > > > make successive calls to FILE_GETOPENINFO_ to learn about
> > > > all the opens.
> > > Additionally, additionally...found and example from COBOL code using item 75 and FILE_GETINFOLISTBYNAME_ (as previously suggested). This would still assume you don't care who/what has it open:
> > >
> > > In working storage:
> > >
> > > 01 WS-PROC-CALL-STATUS NATIVE-2 VALUE 0.
> > > 01 WS-FILE-GETINFOLIST.
> > > 05 WS-FGIL-FNAME PIC X(40) VALUE SPACES.
> > > 05 WS-FGIL-FNAME-LEN NATIVE-2 VALUE ZERO.
> > > 05 WS-FGIL-ITEM-COUNT NATIVE-2 VALUE 5.
> > > 05 WS-FGIL-ITEM-VALUES-LEN NATIVE-2 VALUE 16.
> > > 05 WS-FGIL-ITEM-LIST.
> > > 10 WS-FGIL-SQL-TYPE-CODE NATIVE-2 VALUE 40.
> > > 10 WS-FGIL-FILE-TYPE-CODE NATIVE-2 VALUE 41.
> > > 10 WS-FGIL-FILE-CODE-CODE NATIVE-2 VALUE 42.
> > > 10 WS-FGIL-IS-OPEN-CODE NATIVE-2 VALUE 75.
> > > 10 WS-FGIL-LMOD-CODE NATIVE-2 VALUE 144.
> > > 05 WS-FGIL-ITEM-VALUES.
> > > 10 WS-FGIL-SQL-TYPE NATIVE-2 VALUE 0.
> > > 88 NOT-AN-SQL-OBJECT VALUE 0.
> > > 10 WS-FGIL-FILE-TYPE NATIVE-2 VALUE 0.
> > > 88 FILE-IS-UNSTRUCTURED VALUE 0.
> > > 10 WS-FGIL-FILE-CODE NATIVE-2 VALUE 0.
> > > 88 FILE-CODE-IS-0-OR-101 VALUE 0, 101.
> > > 88 FILE-IS-TYPE-101 VALUE 101.
> > > 10 WS-FGIL-IS-OPEN NATIVE-2 VALUE 0.
> > > 88 FILE-IS-NOT-OPEN VALUE 0.
> > > 88 FILE-IS-OPEN VALUE 1.
> > > 88 FILE-NOT-FOUND VALUE 11.
> > > 88 FILE-IS-A-KEEPER VALUE ZERO.
> > > 88 FILE-IS-NOT-A-KEEPER VALUE 99.
> > > 10 WS-FGIL-LMOD-TSTAMP NATIVE-8 VALUE 0.
> > >
> > > in code:
> > >
> > > **** populate the file name and file name length fields first ***
> > >
> > > ENTER "FILE_GETINFOLISTBYNAME_" USING WS-FGIL-FNAME (1:WS-FGIL-FNAME-LEN)
> > > , WS-FGIL-ITEM-LIST
> > > , WS-FGIL-ITEM-COUNT
> > > , WS-FGIL-ITEM-VALUES
> > > , WS-FGIL-ITEM-VALUES-LEN
> > > GIVING WS-PROC-CALL-STATUS.
> > >
> > > **** check the WS-FGIL-IS-OPEN variable or the associated 88-level switches.
> > Would you please post a link to the document where item number codes and its usage can be located. I guess how did you know item number 75 will return file open status? what would be the item number to determine security violation (AKA Error 48) if a process is trying yo open a file that is secured "UUUU" . Thanks in advance.
> I'm not quite sure what the second part of your question is asking for. If you want to know the item code that shows the file security setting, that is given by item 62, but you probably also would have to look at item 58, which tells you the userid of the file owner, and item 59, which tells you whether the file is under Safeguard security or not.
>
> Only the process that tried to open a file will get the error 48, so I'm not sure what that part of the question is about. The FILE_OPEN_ call that got the error 48 will have 48 returned from the call. If the older OPEN procedure was used to try to open the file, you'd get the error number using the FILEINFO procedure. As far as I recall, there is no way for one process to tell what file error another process got, except maybe using the procedures intended to implement debuggers, which I'm not familiar with. I have a feeling that is not what you are asking about, anyway.

As usual very helpful and informative. I genuinely appreciate your help and time. Thank you!