File Locks On "Deliver To"

[jyoung]

I think this may be related to this post http://vlforum.lansa.com.au/viewtopic.php?f=3&t=1220.

I am "delivering" our VLF-ONE application to production, everything going fine, then on one File I get an error stating the FILE could not be processed.

F03B11 Error.PNG (71.47 KiB) Viewed 11006 times

As Art mentioned in the above linked post, I think this has to do with locking the file when creating the OAM. This is a "Other" file, so it should not be trying to do any maintenance on it, just create the OAM.

Is the problem because other users are using that File? How do you handle this? Do I actually have to kick those people off or wait until they are not using it? Is there anyway to create the OAM without locking the File?

Edit
Further investigation to the File in question, tells me that this file is used by pretty much everything (users and other systems) and is never really unlocked, except in very early morning hours after the system has been bounced and no one or no thing has accessed it yet.

[KevinW]

Most installations have a maintenance window when production users are either not there (before or after normal hours, straight after a back up etc), or announce one in advance. I am surprised that you have not had previous issues.

Do you expect that after a certain date and time users will all be using the latest delivered to version? Are you doing anything to make this so? What happens if the new OAM has a trigger function but the old one doesn't and some users are using the old OAM and some are using the new OAM? I could go on.

[jyoung]

There is no maintenance window. While users are "using" the file during normal working hours, it is used by other systems namely our ERP system. That system does get "bounced" automatically around 11 pm every night.

There has not been a previous "deliver to", this is the first one as it is the initial deployment.

We are a small shop and not constrained by red-tape procedures where we can only deploy / update on x date at y time. We've never had a problem before, however this shop is new to LANSA and this is only our second application to be deployed to production.

I really don't want to get into the habit of having to come in late at night / early morning to deploy updates. I get that we don't have a CI/CD option available yet (hint to the LANSA folks this would be ideal). With no automation tooling that seems like the only option.

I still don't understand why it has to obtain a lock in the first place, but I take it that it was "designed that way".

If I already have the OAM compiled from our dev server, can I deploy it instead of having production compile its own?

[atostaine]

If I already have the OAM compiled from our dev server, can I deploy it instead of having production compile its own?

I think that would work. You can replace a *srvpgm object while it's in use.

[jyoung]

In the "Add Files To List" menu option when working with export lists, there is the 'Comp Form' option.

export list.PNG (13.69 KiB) Viewed 10975 times

The documentation states that

Beside a chosen file, enter a 'Y' to indicate that the file definition is to be exported in 'compiled' or 'ready to use' form. If this option is used, the file will be usable as soon as it has been imported into the target system. If this option is not used, the file definition will have to be 'made operational' on the target system after it has been imported.

I take it that by 'ready to use' it means that it is already complied.
If I include it in an export list, export that list to a save file, will it still need a lock on the File?

[jyoung]

Well that was frustrating. I've mentioned better error messages before http://vlforum.lansa.com.au/viewtopic.php?f=6&t=1237 and come to find out this was not a locking problem at all.

The problem was that the file F03B11 is in USPYDTA in our dev server which is where I loaded it from, however it is in USPDDTA in production.
So the error (while it was probably trying to lock it) was in fact because it could not be found. Again, a better error message "The File could not be found" would have saved me two days of research and reading trying to figure this out.

I was discussing this with my boss and showed him the error and he instantly knew that USPYDTA did not exist on production.

Every other File we have worked with has been loaded from dev in the XXDTALIBT library and in production they are in XXDTALIB. Production just so happens to have a XXDTALIBT that has empty files in it. Of course, now going forward if that happens again, at least I know the first thing I will check.

This experience brings up another question however; where should you load Files from if Files are in different libraries in different environments? If I loaded from Production I would have the same problem when deploying to dev.