[Dee Davis]

Dennis,

Check your PM here.

Dee

[Dee Davis]

We use a TRXID proc to create routes as ORM_LAB, ORM_RAD, etc.  In the proc your goal is to return the trxid upon completion.

[Dee Davis]

Thanks — I just retested taking out the save_ob_msg in the above configuration.  It does work correctly then.  Something must be wrong with that one in the recover_56 set.

Just for one final point of clarification — are these correct?

1. If in manual mode — we would need to KILL or dispose of OBMSGID.

2. If in auto mode – we would NOT need to dispose of OBMSGID.

Thanks — just about done.  Thanks for your patience.

Dee

[Dee Davis]

Thanks, Charlie.  This does help me verify some of my understanding.

Although we will most likely be converting to the auto-resend, I really want to understand why I am not getting the behavior I’m looking for. (This is in case we “miss” a connection on conversion day.)  We basically renamed the recover_56 procs to our existing proc names (and renamed the old tcl file).  I just can’t figure out if it’s the way the procs are or a bug…

So — the configuration…

Send OK :we have save_ob_msg  I recognize it is just continuing MSGID instead of saving to global.

Reply-Gen: resend_ob_msg_38

tps-ib-reply: kill_ob_save, kill_reply (KILLREPLY of MSGID) — we do not validate_reply or check_ack for the test I am doing.

I can see echos from sms-ib-reply after the ACK hits — but it keeps resending the same message and echoing (from the reply-gen).

I questioned whether with save_ob_msg we needed to KILL the OBMSGID handle in this situation as it was not being done in the proc —   Is that done by the engine innately?  (It seems like there was no state 16 in the db then) Also, because we kill_reply on the MSGID, I thought perhaps we didn’t need kill_ob_save at all since it was doing KILL of the MSGID handle rather than KILLREPLY).  Still get a resend…

We are using PDL-tcp with mlp_tclp.pdl   — Is the problem with the PDL when in non-auto mode??  I suppose we could keep our old recover_38 procs with the extra global in memory since it worked — but I really want to understand what’s happening.

Thanks in advance again.

[Dee Davis]

All, the /etc/resolv.conf file was the issue.  On our previous versions 5.3 — Cloverleaf used /etc/hosts.  We didn’t even have it on the box.

Thank you for everyone’s input.

Dee

[Dee Davis]

One more example — same box — all through command line to avoid client connectivity:

Started process in 5.6:

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] CLOVERLEAF(R) Integration Services 5.6P Rev1

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] Linked by root on host=(AIX lion 2 5 000FA26D4C

00) at Thu Apr 24 00:20:47 2008 in /usr/work/jerickso/cloverrel/cloverleaf/engine/main (build 2)

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] FEATURE cl-pkg-cl hcilicmgrd 5.6 12-oct-2008 un

counted 83155693F03B

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52]    HOSTID=f631f4c ck=107 category=testdev

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] FEATURE cl-intfc-thread-182 hcilicmgrd 5.6 12-o

ct-2008 uncounted BA854EA205A6

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52]    HOSTID=f631f4c ck=103 category=testdev

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] FEATURE cl-mm-master hcilicmgrd 5.6 12-oct-2008

uncounted 181750D8C9E1

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52]    HOSTID=f631f4c ck=144 category=testdev

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] Started at Fri Jul 25 09:37:52 2008

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:37:52] Engine process is 42942 on host mchsie5

(we are still waiting…)

In 5.3:

[prod:prod:INFO/0:  STARTUP_TID] QDX(TM) Integration Services 5.3P Rev2

[prod:prod:INFO/0:  STARTUP_TID] Linked by root on mako at Fri Nov 19 22:19:01 2004 in /work2/jerick

so/cloverrel/cloverleaf/engine/main (build 1)

[prod:prod:INFO/0:  STARTUP_TID] Started at Fri Jul 25 09:40:16 2008

[prod:prod:INFO/0:  STARTUP_TID] Engine process is 86854 on host mchsie5

[prod:prod:INFO/1: adt_anc4_cmd] Msg space limit is 0[prod:prod:INFO/0: adt_anc4_cmd] DiskQue Minimum # of Messages/que: 50

[prod:prod:INFO/0: adt_anc4_cmd] DiskQue Virtual Memory percent:75.000000

[prod:prod:INFO/0: adt_anc4_cmd] Applying EO config: ”

[prod:prod:INFO/0:adt_anc4_xlate] Applying EO config: ”

[prod:prod:INFO/0:    isqlabint] Applying EO config: ”

(HL7_REPLY_GEN/isqlabint) HL7 replies will be generated.

(HL7_REPLY_GEN/isqlabint) Sequence number checking disabled

Thanks again…

Dee

[Dee Davis]

Hi, Charlie ..

This is really strange.  There are no delays on our 5.3 root.  We took everything down in 5.6 (very painful) and stopped daemons. This morning we stopped and restarted the host server.  Started the Site Daemons.  We cannot get a response to hciprocstatus (it timed out). Looked in the hcimonitord log; it looks now like it took 4 minutes to do get past the pid number:

[prod:prod:INFO/0:  STARTUP_TID:07/25/2008 09:23:52] Monitord process is 57228 on host mchsie5

[prod:prod:INFO/0:  hcimonitord:07/25/2008 09:27:38] Applying EO config: ”

On same box .. came up immedicately in 5.3 — but there are no timestamps; I just started and went to the log:

[prod:prod:INFO/0:  STARTUP_TID] Started at Fri Jul 25 09:34:47 2008

[prod:prod:INFO/0:  STARTUP_TID] Monitord process is 71636 on host mchsie5

[prod:prod:INFO/0:  hcimonitord] Applying EO config: ”

I am unsure as to what to look at… Thanks for picking this up.

Dee

[Dee Davis]

I have two staff who we are interested in getting Level 2 training for.  I sent you a separate email.

[Dee Davis]

I actually performed a data conversion on the engine with more records than that. I spent quite a bit of time optimizing so we did not overload the database.  There were different stages of the conversion in different processes. Most were fileset-local connections; some were looking at one huge file where records had to be peeled off; others picked up individual files that had been sent out by another stage.

In optimizing inbound fileset-local connections, I looked at: the read interval, max messages and scan interval in the connection set up as well as translation process throttling.  The goal was to have as few messages as possible in the database by the next read but not to leave time where no processing was happening. Also, so that if we had to shut down a process, there was actually some read time for the command thread. Each inbound thread (in different processes) ended up having different “optimal” settings depending on what was happening in the process (parsing the initial extract file, detailed translation, script only, etc).  Examples (read interval, max msg, 3600 scan interval) were 180, 76, 3600; 75, 1000, 3600; 400, 200, 7200.

Bottom line — it can be done without database issues. You just have to work at it.

[Dee Davis]

Thanks, Jonathan — definitely needed a “cool head” look.  Too much happening here and this was a request by the vendor at the last minute.  We were trying to keep the “singles” working while getting the new translate.

[Dee Davis]

When I have wanted to blank out a sub-subfield I use:

copy @null   to  1(0).1(0).1(0).OBX.00571.[0].[1]

OBX|1|FT|76094.3&GDT||||||||P

becomes

OBX|1|FT|76094.3||||||||P

[Author]

Replies