***** A D A B A S BASIC SERVICES *****
DBID - Display Command Queue -
Mark entries with 'S' to select :
M I TID I Jobname I Cmd. Status I PrtyI Fnr. I Cmd I Cmd.Seq.Nr
-----------------------------------------------------------------------------
I C695F71C I I In Process I 234 I 63 I N1 I 186124
I C695F71C I I In Process I 234 I 63 I L2 I 186125
I C695F71C I I In Process I 234 I 63 I BT I 186126
I C695F71C I I In Process I 234 I I CL I 186127
I C695F71C I I In Process I 236 I I OP I 190239
I C695F71C I I In Process I 236 I 63 I L2 I 190240
I 63E2E4F6 I I In Process I 244 I I UC I 191340
I I I I I I I
I I I I I I I
I I I I I I I
I I I I I I I
I I I I I I I
PF1----- PF2------ PF3------ PF4------ PF6----- PF7----- PF8----- PF12-----
Help T-in/Jobn Exit Refresh - + Menu
How at command seq …24 does it issue a N1 and then issue at …25 an L2 and at …26 issue a BT and at …27 a CL – without waiting for a response from the one before? Doesn’t make sense to me.
Brief background - Trying to read (physical) ADABAS, processing data and inserting records back.
It makes no sense then. It looks like the sequence of commands one would expect to see for a single user. If you looked at the command log or test dblog, for example, you might see those commands in sequence (new record, read physical, backout transaction, close, open, read physical…).
I don’t know how you could be seeing queued up in the command queue a bunch of commands from a single user from a single terminal id against the same file. Even different emulator windows would appear to have different terminal ids even if it is the same user, and as soon as a command is processed, it is no longer on the command queue (unless it is thrown back) so how would you place any subsequent commands on the queue until that one is processed?
Correct - the gaps in command sequence numbers indicates that other users have placed commands on the queue, and those commands have already been processed (or are being processed).
Ats: you say you are doing “read (physical) ADABAS, … and inserting records back”. A caution: you need to be careful when doing updates and inserts while processing with a READ PHYSICAL. The physical order of records can change when you do updates (if the record size increases) and inserts.
You may end up re-reading records already read and/or reading records you have just inserted. If either of these is an issue for your application, use a different approach (read by isn, queue up updates/inserts by writing to another file or work file, then apply them after leaving the read physical loop…)
What I am still curious about is how it is possible for all those commands from a single user/session/program to all be waiting in the command queue.
If a program is coded to do a sequence of events, such as reading the record in physical sequence, then deciding to update or store, then committing the record, then reading the next one, I would expect the command queue to not have the whole sequence of events waiting to be processed. Typically, if I enter a READ loop, Adabas must fulfill the request to get me the next record before I move on to process the subsequent lines of code up to the next database call (ie. UPDATE, STORE, READ the next record, etc). Once fulfilled, it would not be visible in the command queue any longer since those are calls waiting to be processed.
Ats, can you share the code with us, please, that is generating this odd-looking command queue?
a) a user is identified from Adabas by it´s 28 byte long communication id, this has to be unique. Unfortunally the display command queue only shows the right most 8 byte of this id, in the display user queue you can select one specific entry and do a display there, then you can see the full 28 byte.
b) if the same user (same 28 byte comm id) issues a second command it should receive a rsp-153, in your case it seems that the 28 byte commid is different otherwise the rsp-code would have occured
c) the 28 byte communication id can be build from the user program (so called x48 call - is used for example from Natural when running ADAMODE=2, Nat does build two different users for one session) or it assembled from ADALINK and SVC and contains things like the CPUID, the TID generated by ADALINK etc.
d) so seeing the same rightmost 8 byte in the display of the commandqueue does not mean that there is something wrong, it is maybe not seen so often because mostly the rightmost 8 byte do differ. As long as the 28 byte are unique and used ´correctly´ there is no problem.
You should either check with the provider of the user program or look into more detail in the corresponding userqueue elements to see more. You can also look in the command log or use Adabas Review to see the sequenece of the commands and there you can also see the 28byte communication id.
Hope that helps,
Regards,
Uschi
P.S. the other comments with the read physical are valid
