We use UniData/HPUX w/ SB and Redback. We are running Epicor's Avanté which
uses iConnect.
For arguments sake, I have 3 UniData accounts: TEST, PILOT LIVE.
I have 3 web sites (TEST, PILOT LIVE) that connect as you would expect.
3-4 weeks ago, a change was made in Sales Order Entry in SB. I
Given that Corrupt is missing a T (itself being corrupt?) I would think it's
not an OS related message.
Since your HPUX, can you do a file content find in unix for RECORD CORRUP! to
find out where it's coming from?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
Sorry for the typo.
We thought of looking for the program giving the error. We do not have the
source code for it, so even if we found it as a string, we could not read the
rest of the object code. Even so, I have tried doing an ESEARCH on some of the
SB files, but I have yet to find it.
Since it's in the Redback log, that's where I'd be looking.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R.
Sent: Monday, November 25, 2013 9:06 AM
To: U2 Users List
Subject: Re: [U2] Mysterious
Hi John,
ok, so let's think this through...
RedBack is using an iConnect agent to login through SB+ and execute the screen.
That message is an SB+ message.
So...my first question would be - are the LOGIN paragraphs the same between
accounts where it's working and where it's not?
The 2nd would
Yes - the LOGIN paragraphs are the same.
Yes - the iConnect agents are essentially the same (paths are obviously
different) and they are all enabled. The last change I made to iConnect was
3-4 weeks ago to map a new field and that worked (and is still working in LIVE).
I have done an ESEARCH
II is whatever SB+ system it is logging into.
Whatever SB+ user is being used to log in doesn't have access to the account.
The message is stored in the ERROR item of the DMCONT file - attribute 115 - so
you won't find that using ESEARCH on a BP file.
Haven't used redback so I don't know what
is WW.SB.RB cataloged in pilot and test?
Is BP IILOGIN the same?
If yes to both, take redback out of the picture, along with the screen changes
(it's not making it to the screen yet...)
Do you get the same message when you login through SB+, with the same user that
the iConnect agent logs in
Dave,
Yes, I understood (or assumed) that the II was the SB+ system, just not WHY
it thought something was corrupt.
I found the error message just like you said in DMCONT ERROR. I have never
seen this before. The record looks like a bunch of generic error messages that
can be used as
Amy,
Yes, both look good.
Based on the 1st word in the message (II), this really looks like a SB error.
I get NO errors if I login manually using the Redback UNIX login, cd to the
TEST account, launch UniData (udt), and type in the iConnect login/pw. That is
as close to simulating iConnect
Yes, agreed. So you're using the sb+ uid/pw of the iconnect service manager?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Israel, John R.
Sent: Monday, November 25, 2013 11:36 AM
To: U2 Users List
Subject: Re:
Amy,
Yes, I am using iConnect's SB login/pw as soon as UniData/SB launches and I get
right in. I looked at the date stamp on the iConnect data and it has not been
touch in a LONG time.
What is different between this and running it on-line?
Since I can get in that way w/o any problems, why is
To convert the first character of a regular ASCII string to uppercase, I'd use
OCONV(STRING,'MCT') so that STRING is output as String. However, this
doesn't seem to work for Spanish accented characters. The machine is UV
11.1.11 with NLS enabled.
What is the most elegant way to convert a
Any consideration of converting the accented character to an unaccented
character first?
Not perfect but it works 99% of the timeand then when you export the name
to another company
All they get are unaccented letters.
George
SUBROUTINE REMOVE.ACCENT(INDATA,OUTDATA)
*
We
The difference is, when you come in through RedBack it's using the agent
itself, so it sees it as a phantom user.
It may be easiest to stick a debug in IILOGIN - check around line 46 (in our
version), for comment: 'Check for iConnect Phantom processing'. This would also
make sense
Amy,
I do have a pointer to ECL_PHPARMS.
Putting a DEBUG in IILOGIN would not work for StoreFront because have no
session to interact with the debugger, just a browser. However, that gives me
a few idea. I build a log that tracks how far I get and when I fail to get to
a certain point,
I believe the program that generates that message is MM in DM. The error
signifies that the calculated checksum in the DMSECURITY record is not
correct for the version of SB+ in use.
On Monday, November 25, 2013, Israel, John R. wrote:
Amy,
I do have a pointer to ECL_PHPARMS.
Putting a
John, look for [E115]. That's how the error will appear in the SB+
routines. I'm guessing that the problem is that RB is connecting to SB
through the install accounts but DMSECURITY is being referenced locally,
hence the checksum mismatch.
On Monday, November 25, 2013, Israel, John R. wrote:
18 matches
Mail list logo
