What Happens when you "Deliver To"

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
jyoung
Posts: 689
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

What Happens when you "Deliver To"

Post by jyoung » Wed Nov 15, 2017 9:22 am

I've mentioned a couple times that I use "Deliver To" to deploy components to our iSeries. Here is one such conversation https://forum.developer.lansa.com/viewt ... 3572#p3572.

What has never really been discussed are the pitfalls of doing this and/or what happens when you do this.

I have never had a problem with it ... until now.

What happened is that when I "Delivered" the components, the message "Job XXXXX/DCXPGMLIB/XXXXXX submitted to job queue QBATCH in library QGPL" showed up as it normally does, but then it got hung up. Come to find out that the job was stuck in the queue behind a long running job.

During this the site went down and was returning 404 errors. We ended up trying to restart the subsystems and then only some of them would come back. After promoting the above mentioned job to get it completed and restarting the subsystems again, everything come back online.

I can't find any documentation on what happens when you use "Deliver To".

So what happens when you do this?
What subsystems are stopped?
What do you do if it hangs up?

atostaine
Posts: 537
Joined: Wed Jan 20, 2016 7:38 am

Re: What Happens when you "Deliver To"

Post by atostaine » Wed Nov 29, 2017 3:07 am

I don't use deliver to. I guess it deletes the existing object, then submits another job to compile it?

You can change your job description to use QCTL, which is shipped as *nomax active jobs.
Art Tostaine

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: What Happens when you "Deliver To"

Post by Stewart Marshall » Wed Nov 29, 2017 3:32 pm

If your IBM i is acting as a master system, Check In and Check Out should be used.

If you're using Version Control, your version control system is effectively your master. The result is that the IBM i is really just another slave system, which means the use of Deliver To is required.

Under the covers, Deliver To behaviour is basically a Check In as far as the IBM is concerned.

Object definitions are stored in the repository, compiles are submitted as required and any associated files such as generated JavaScript are stored in the appropriate folders.
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

jyoung
Posts: 689
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: What Happens when you "Deliver To"

Post by jyoung » Thu Nov 30, 2017 1:44 am

Hi Stewart,

The iSeries in question is our production system.

We have two systems (dev and prod). We Check In/Out of Dev as it is our "master" system.

Its getting the components to production that has always been the pain point.

After a component has been checked into the master system and tested and before the task is finished, we use "Deliver To" to get the components to the production server.

Assuming we use an Export List to move the components, will the same issue not occur?

Hi Art,

I don't know what it does but it seems like it stops the subsystems, then compiles the objects then starts the subsystems back ....?
It seems like that only happens for "server side" components such as ServerModules and Functions. For "web components" its my understanding that those are compiled on the workstation and then copied up the to the server in an essentially a "hot swap" fashion. Of course I could be completely wrong here. lol.

Hot swapping is always complicated, but I am curious if it could be handled similar to how cloud deployments work. Thinking out load here; submit the job to compile first, don't stop the current subsystems. Then once the compile is complete, start a new subsystem with the fresh components and then shut down the old subsystems. Sounds simple, but I know the details would be difficult.

dianejoester
Posts: 15
Joined: Mon Nov 02, 2015 2:52 pm

Re: What Happens when you "Deliver To"

Post by dianejoester » Thu Nov 30, 2017 3:23 pm

Hi Joe,

The answer to
Assuming we use an Export List to move the components, will the same issue not occur?
is no.
Here are some of the reasons why:
  • Export can ship compiled objects (the same objects that were used for testing) so there are not separate jobs required to compile objects when importing to the production server.
  • Import is a single job on the production server (other than process compiles if you have them), so the current production system is not impacted until the import starts to execute.
  • You can also use job management to schedule the import job at a convenient time to be even more flexible with production usage. There is no requirement to be connected to Visual LANSA as there is to drive the Deliver To.
Finally, the "master" is the location of all master repository objects and this should be where any objects are sourced for production systems.
If the "master" is a VCS, then objects for production should be sourced from a Build/Test Visual LANSA system.
If the "master" is on an IBM i, objects for production should be sourced from the Build/Test LANSA for i system.

jyoung
Posts: 689
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: What Happens when you "Deliver To"

Post by jyoung » Fri Dec 01, 2017 1:47 am

Hi Diane,

Thank you so much for that explanation!

Whenever you have different ways of doing the same thing, it really helps to understand the pros and cons of each way.

Thanks!
Joe

Post Reply