I am quite new to the FOCUS.

My main task is to add new fields on a segment. and use REORG/DUMP and REORG/LOAD.

The REORG/DUMP works fine. But during the REORG/LOAD

I go the following FOC395 error
FOC395) CANNOT WRITE TO A FILE WHOSE 'USE' COMMAND REQUESTS 'READ'
If a file is specified as 'READ' in a USE command, a MODIFY
procedure may not attempt to INCLUDE, UPDATE or DELETE data.

Is there anyone who can suggest any solution.

Note: My focus database is located at TSO (mainframe)

This message has been edited. Last edited by: FP Mod Chuck,

Seems to be a stupid answer but AFAIK, I will look at the table access properties to ensure that you have the read/write access and that the table is not locked to read only.

I think that it should be the starting point

And this may help
Creating and Rebuilding a Data Source

Or perform a search in Technical Content for the words : REBUILT REORG

From the error message, it sounds like you might have...

USE
fileid READ
END  

somewhere?

In any event can you do a

? USE
-EXIT  

ahead of your REBUILD code and observe the results?

Thanks you for Martin and David's reply.

Since my focus version is a legacy Focus in mainframe.

The problem occurs when I went into the native focus environment.

1. REBUILD/REORD/DUMP - all is fine at that stage.
2. The I use TED master(fileid) to edit the old master and replace by by new master file definition.
3. REBUILD/REORG/LOAD the error message FOC395
comes out.

Anyway I will try out David's suggestion.

Thanks everyone


Francis

David,

I try to do the ? USE

DIRECTORIES IN USE ARE:
INTEREST ON FOCSU
INTEREST LOCAL

As you know, we use CLIST to trigger the Focus application. How can we tell my access in READ only.
in FOCSU - focus file A
LOCAL - focus file B for testing.

any suggestion ?

Francis

OK, so INTEREST is the name of the database you are doing a REBUILD on?

Given the results of your ? USE, it looks like INTEREST is running under a 'sync' machine (Simultaneous Usage [SU]). Is that correct?

I haven't been on FOCUS for z/OS in a long time, so take this with a grain of salt: I seem to recall that we didn't do a REBUILD on a FOCUS database while it was running under the SU.

I seem to remember our SU's ran at certain times of the day, and we would REBUILD when the SU was down.

David,

You are right we are running the SU machine for
Multiple user.

the INTEREST is the focus database.

The name OF FOCUS DATABASE that run under SU

UQA999.FOCUS.INTEREST

Then I have my own CLIST

PROC 0 MASTER('USZ999.INTEREST.MASTER') +
FOCEXEC('USZ999.INTEREST.FOCEXEC') +
INTEREST('USZ999.FOCUS.INTEREST') +
PCTFILE('USZ999.FOCUS.PCTTABLE') +
DSPRNT('&SYSUID..FOCUS.DSPRNT') +
DEBUG +

Are you saying that I have to bring down the SU
such that I can REBUILD ? or wait until SU is down ?

Question: After the SU is down, am I rebuild the database from SU or my own database?

May be that is a stupid question but I really want to know.

Thanks in advance again.

Francis

quote:

Question: After the SU is down, am I rebuild the database from SU or my own database?

As I recall we followed this path:
1. Perform REBUILD REORG on a personal dataset. Test and verify.
2. Perform REBUILD REORG on a dataset used by the TEST SU. The TEST SU had a shorter uptime, and was used for purposes such as this. Test and verify.
3. Perform REBUILD REORG on the production dataset.

quote:

Are you saying that I have to bring down the SU such that I can REBUILD? or wait until SU is down?

We didn't ask our FOCUS DBA's/Site Coordinator's to bring up and down SU's. For many reasons, one of which was they had an uptime SLA. We would do maintenance like this during off hours (when the SU was down).

The way I thought of it is that while the SU is running you are really hitting a intermediary (communication facility) and not the physical database, which the SU is up and hitting the dataset.

For sure, check at your site, if you haven't already, if there are any standard protocols for doing a REBUILD REORG. For example, we had a standard job/focexecs that performed the DUMP phase, updated the MFD, performed the LOAD.

By definition a REBUILD is updating database internals, so you want to test, verify, and follow any site standards.

As always, back ups are your friend.

While I miss FOCUS for z/OS, it has been a while, so while I hope this helps, your mileage may vary.

This message has been edited. Last edited by: David Briars,

David,

I just follow the steps that our previous maintenance guy did.

1. Ensure that you have exclusive use of the INTEREST application (when SU is down) or ask the users to suspend input (if that is an option) and perform the changes in test and copy the new file definition, databases, and programs into production before the user's next input cycle.

2. At the INTEREST main menu press the PF3 key to enter native FOCUS

3. At the > prompt type in REBUILD

4. Select option 2. REORG

5. Select option 1. DUMP

6. Type INTEREST

7. At the ANY RECORD SELECTION TESTS? (YES/NO) type N

8. When the DUMP has finished (keep pressing the ENTER key until the > prompt appears)

9. Type TED MASTER(INTEREST)

10. Type NUM ON

11. At line 1, position 1 of the INTEREST file definition type D9999 to delete all the lines

12. Type GET MASTER(INTERDBA) to copy the INTERDBA new file definition into INTEREST member

13. Type FILE to save the changes

14. Type REBUILD

15. Select option 2. REORG

16. Select option 2. LOAD
FOC395 occurs during LOAD

17. Type INTEREST

18. Keep pressing the ENTER key until the > prompt appears

19. Type FIN to exit the application

20. Copy the new FOCEXEC members

That is exactly the steps that you mention.

I will have the testing SU down again today to do one more testing.

Francis

David,

After the testing SU is down. I still get the same error FOC395.

Our legacy focus seems fine when I check my master definition, no access restricted.

Any additional suggestion?

We have one production environment and one development environment.

I copy the Production one to my development after the dev FOCSU is down.

Francis

In addition to doing the REORG while the SU is down, you might want to check:
* your allocation to see if you have exclusive control and are not sharing it with anyone. DISP = OLD, not SHR.
* sounds like you are running the REORG under your ID, is so, does your ID have READ and WRITE access?
* that your profile isn't running a USE command on the file, ? USE should be able to tell you.

For sure though, follow your site standards, the manuals, and check with the IB Helpdesk if you still have questions.

Your first post says you are new to FOCUS, so you should know a REORG for a new person can be a bit of a challenge.

This message has been edited. Last edited by: David Briars,

First, SU must be down.
Second, I never, ever rebuild/reorg into the same mfd name. I know one is on SU and one is local, but there are certain things in FOCUS I don't trust (after being intimate with it for 40 years).

So,
Bring down SU.
Backup INTEREST and its mfd.
Rebuild/Reorg from INTEREST into INTERDBA.
Delete INTEREST and its mfd.
Rename INTERDBA .mas and .foc files to INTEREST.
Restart SU.

Donna,

I will give a try during March time.

I will keep you and David know.

Thanks.

Donna and David,

I believed I already found out the problem for FOC395 problem.

After the SU is down.

There is a Profile member using
EDIT UQA999.INTEREST.FOCEXEC(PROFILE) -
USE
INTEREST ON FOCSU
INTEREST LOCAL
END

I commented out the above as
-*USE
-*INTEREST ON FOCSU
-*INTEREST LOCAL
-*END


Then I can DUMP/LOAD the INTEREST database.

Remarks: Loading is good.

After my LOAD is done, then I uncomment the PROFILE again and bring up the SU again. It looks good to me.

One more time, many thanks to Donna and David to spend time on my problem. (RESOLVED)