ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

how to start a job/program in QSERVER

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • how to start a job/program in QSERVER

    Hello again!!

    I have a server program, discussed other places here in this forum, that is basically a telnet server product.

    How do i start that program in QSERVER, assuming I don't want it running in QBATCH and I don't want to create my own subsystem?

    also, how and why is QBATCH the default and can I change the default?

    thanks for the help, in advance.

    matt
    Some people are like slinkies.
    Not really good for anything, but
    you can't help but smile when you
    see them tumble down the stairs.

  • #2
    Have you tried ADDPJE and pointing to QServer? I assume this telnet-like program isn't actually the telnet server.

    Comment


    • #3
      Ok I see, adding a "prestart job" to the subsystem description. I hadn't thougth of that, but it sounds like it would work. wouldn't that require a restart of the subsystem, then? if so...

      now, just to be a pain 'cause that's the way customers are....

      I was thinking of using SBMJOB and putting the job in the QPWFSERVER JobQ, which i think funnels jobs to QSERVER. would that work without restarting the subsystem?

      thanks,

      matt
      Some people are like slinkies.
      Not really good for anything, but
      you can't help but smile when you
      see them tumble down the stairs.

      Comment


      • #4
        It should work

        Yes, it should work. This is baically what happens when you SBMJOB to a QBATCH jobq - it runs the job from QBATCH instead of QINTER.

        I would suggest however, creating your own jobq in QServer instead of using the QPWFSERVER if this is more than just a test. That way you don't risk interfering with anything thats already running there.

        BTW - setting up yuor own sub-system isn't very hard.

        Comment


        • #5
          so i gather that the 'default sbs' is QBATCH for the SBMJOB command.

          as far as the subsystem, I have created a subsystem and even modified QSTRUP to start it. However, the company i work for needs some "as400 guidelines", because, well... not everyone with an as400 is as smart as the people in this forum.

          question:

          when you say to create a JOBQ for injecting jobs into QSERVER so as not to "risk interfering with anything that's already running there" do you mean interfering in QSERVER or the QPWFSERVER jobq? can you give me an example of the type of contention you're talking about?

          next question:

          other than personal preference, can anyone out there give me some good technical reasons that a separate subsystem is better
          than QSERVER?

          because this is what I am thinking: "if the tcp/ip server we're installing is going to be moderately used, and is one of several servers (www, ftp, telnet already in QSERVER), then Q SERVER is a good place to put it. however, if the machine's PRIMARY purpose is to run our tcp/ip server, then it should get it's own subsystem".

          final question:

          would that be good advice for our customers?

          thanks again,

          matt
          Some people are like slinkies.
          Not really good for anything, but
          you can't help but smile when you
          see them tumble down the stairs.

          Comment


          • #6
            just a quik note

            Matt,

            During upgrades like for example the one you just did.

            All subsytems jobqueues, auto start job(s) etc..... that belong to IBM(start with "Q") will be REPLACED --or REMOVED.

            If you place your application in any of these subsystems and modifiy the jobqueues ALL changes will be lost when upgrading.

            It would be best to create your own subsystem for example "ATLANTIS"

            Just my thoughts.

            jimmy

            Comment


            • #7
              did not know that! i will add it to my notes. i tend to agree with you that a new subsystem is still the best option, but of course we can't dictate those kinds of things to our customers.

              also, since upgrades seem to happen every few years... it may be something some customers can live with. i still tend to think, for a small installation especially, running in QSERVER would be an option. and since it can be done in a few steps, it looks like a good option. believe it or not, i have been getting more resistance to altering QSTRUP than anything else, so I am trying to offer an alternative that avoids QSTRUP.

              so...

              i tried to do a SBMJOB to jobq QPWFSERVER and no error, but no server either. i checked the job log and it seems to be giving me an error about needing a 'routing entry'.... but ADDRTGE is foreign to me.

              can someone dumb down a discussion of routing entries and what i should use?

              matt
              Some people are like slinkies.
              Not really good for anything, but
              you can't help but smile when you
              see them tumble down the stairs.

              Comment


              • #8
                When you create a Jobq, you attach it to a sub-system. You can add jobs to (almost) any sub-system, but the sub-systems are configured for their expected use. For example, jobq running in QCTL runs at priority 10 by default, whereas QBATCH will run it at priority 50. Put a big "batch-type" job in QCTL, and everyone else might as well go home until the job finishes. Time-slice and memory pool allocation are also configured this way.

                You don't say why you don't want to run in QBATCH. But my general guideline is that is the job is not unusually demanding on the system, you can prob run it anywhere without problems.

                My reference to using Jobq's that aren't usually used, is that sometimes there can be bottlenecks. Some jobq's allow only 1 job at a time, others several, some unlimited. You can even have it allow xxx jobs at jobq priority1, and a different number at jobq priority 2, etc.

                If you create your own jobq, you can specifiy it as you like, and it won't be a problem if another jobq job has an error and has stopped.

                This is in addition to the fact that when new releases, sometimes PTF's are installed, IBM may change the subsystem and/or jobq spec's.

                I don't know what your "tcp/ip" server does. If its not a big deal, putting it in QSERVER should work.

                Comment


                • #9
                  now i NEED to do this!...

                  I don't want to run in QBATCH because most times it "clogs up" QBATCH. the tcp/ip server I am dealing with is like a web server... it runs as a service/daemon then spawns new jobs to handle connection requests. so we have found that running in QBATCH, it never terminates and jobs pile up behind it.

                  currently I need to figure out how to do this. this week and next i will be at a customer site doing a "proof of concept" demonstration with the customer's data. so, i really don't want to create a subsystem there just for this, but i can if i have to (however, they may not let me, I don't know at this point). so, i'll be at the customer site for a few days, and when i leave i'll need to clean up and remove the software.

                  as i said previously, I tried the SBMJOB command and it failed; the server was not there waiting for connections.

                  Can someone give me some specific steps and commands to do what I want to do?

                  thx
                  Some people are like slinkies.
                  Not really good for anything, but
                  you can't help but smile when you
                  see them tumble down the stairs.

                  Comment

                  Working...
                  X