Accessing Writes/Updates in Commitment Control
Q I have a question about writes and updates in commitment control. I start CMTCTL and call a program that writes both an order and some associated detail records in other files. The activation group name in these programs is *DFTACTGRP.
After the order and the detail records are written, another program in the process (in activation group QILE) retrieves some information from an EDI database and attempts to update the order. The update is then processed via a module (in activation group QILE) in a binding directory. After the update is completed, the COMMIT is issued and the records are posted.
Sometimes, when the chain to the order file is issued from within the module, we get a message that the record is already locked to the job. On other occasions, everything works fine. This all happens prior to the COMMIT. We are using STRCMTCTL LCKLVL(*ALL) CMTSCOPE(*JOB).
Can a record written under commitment control be accessed for update before a COMMIT operation is issued? Or is the activation group a problem here?
—George Fuste, from the iPro Developer Forums
A The problem may not be the activation group, but the lock level you are using: *ALL means that every record accessed for files opened under commitment control is locked until the transaction is committed or rolled back. There may be occasions where the record is already locked for read. Normally, you use commitment control to keep the integrity of data from a transaction intact. Based on your explanation, you should perform the commit right after your order has been updated from your first program (assuming the data is complete and defines the entire transaction for the order). After that, the data should be available to other programs for read or update.
—B. Hauser and Bluemax86, from the iPro Developer Forums
Determining Single Job Queues
Q How can I tell if a particular JOBQ is a single job queue or not? If job queue X can be attached to different subsystems, how do I know which subsystem my submitted job queue X will run under?
—Cat5ive, from the iPro Developer Forums
A One way is to run WRKSBSD on the subsystem for the job queue and look at option 6: job queues. MAXACTIVE should be 1 for singles. You could do this programmatically using the List Subsystem Job Queues (QWDLSJBQ) API, then look at the max active value from the returned info. WRKJOBQD will show which subsystem the job queue is currently attached to.
You might also need to list active subsystems and then look at the description of each to find the attached job queues. The job queue itself doesn’t determine its max active value, because a job queue attached to one subsystem can be different when attached to another.
Again, you could programmatically use the List Active Subsystems (QWCLASBS) API to retrieve all active subsystems, or you could use the List Objects (QUSLOBJ) API to list all subsystem objects and then call the QWDLSJBQ API to get the job queue entries.
—Lynne Noll and Chris Hird, from the iPro Developer Forums
Finding Uncommitted Changes
Q My save while active is getting errors because there are uncommitted changes on the system, which is probably a program error, but the message doesn't say what changes are uncommitted. How can I see this?
A WRKCMTDFN *ALL shows a confusing list, but I made a little program that committed and updated but did not commit again, leaving uncommitted changes. F11 from the first screen showed YES under local pending changes for my job and no others. Entering a 5 operation on that line (display status), then pressing F6 for Display Resource status, and then entering 1 for operation by Journal gives the last commit number and journal.
DSPJRN JRN(....) FROMENTLRG(number from commit transaction) job(xx/xx/xx) shows the tables being changed after that in that job.
—Lynne Noll (answering her own question), from the iPro Developer Forums
Trapping Connection Failures
Q I want to create a program in which I can monitor and trap a connection failure to FTP on a remote host (for example, if not all FTP server jobs are active on the remote host). Is there any way to detect this and gracefully recover?
— Eli, from the iPro Developer Forums
A Scott Klement’s FTPAPI (http://www.scottklement.com/ftpapi) lets you check to see if the connection failed, determine why it failed, perform retries, and more (tasks which are just too kludgy for the native FTP client). FTPAPI can do a lot more than the native FTP on most systems.
—Tommy Holden, from the iPro Developer Forums