× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hey folks!

Several months ago I loaded this code into my system and thought that I had
the user-id problems cured. Then about a month ago people started coming to
me insisting that they did not make a transaction that they were "credited"
to. Checking the transaction logs, I saw that the user id left "reasonable
doubt" that they had actually keyed the transaction. It seems that this
solution works in many circumstances, but not for all.

Has anyone else had a similar experience with this work-around?

Of course, MAPICS could make this situation go away by making this change on
their own.

Patrick Shrader
White Knight Engineered Products


-----Original Message-----
From: Pete Olshavsky@htol [mailto:peteo@htol.net]
Sent: Wednesday, May 22, 2002 4:43 PM
To: mapics-l@midrange.com
Subject: Re: User ID in the IM Transactions instead of Workstation ID


Paola & group,
    Got to looking at the response George sent. The only problem with this
is .... It is a mod to MAPICS. I am sending you a cl print screen... Sorry
for the lack of documentation.. But what you do is create a CL called AMI3H
and within the cl call the actual pgm AMI3H.
        *************** Beginning of data **********************************
0001.00              PGM        PARM(&LDA &IMH &SHTDN)
0002.00
0003.00              DCL        VAR(&LDA) TYPE(*CHAR) LEN(1024)
0004.00              DCL        VAR(&IMH) TYPE(*CHAR) LEN(577)
0005.00              DCL        VAR(&SHTDN) TYPE(*CHAR) LEN(1)
0006.00              DCL        VAR(&err) TYPE(*CHAR) LEN(1)
0007.00              DCL        VAR(&rtnlib) TYPE(*CHAR) LEN(10)
0008.00              DCL        VAR(&user) TYPE(*CHAR) LEN(10)
0010.00              RTVOBJD    OBJ(AMZPMD) OBJTYPE(*DTAARA) RTNLIB(&RTNLIB)
0012.00              RTVJOBA    USER(&USER)
0014.00  chgvar var(%sst(&imh 4 10)) value(&user)
0016.00              CALL       PGM(&RTNLIB/AMI3H) PARM(&LDA &imh &shtdn)
0017.00 dltovr *all
0019.00 endcl:
        ****************** End of data *************************************

This must of course sit higher in the library list. But it is not a mod to
Mapics. So when you go to the next release all you should have to do is
recompile. (Unless they add a parm or change the layout of imhist) I ran a
few test and seemed to work fine. May want to try with more than one user. I
am at R6. If you are at a lower Release may need to download and look at pgm
AMI3H to see what parms are passed to the pgm..

Hope this is useful
Pete Olshavsky
Ind. Mapics Analyst/Systems Analyst

----- Original Message -----
From: <pgroeber@bellsouth.net>
To: <mapics-l@midrange.com>
Sent: Tuesday, May 21, 2002 2:43 PM
Subject: User ID in the IM Transactions instead of Workstation ID


I have a question I hope somone on this forum can answer.  Does anyone know
an easy way to change the data being entered into the Workstation ID field
on IM transactions, to reflect the User ID data instead?  The Workstation ID
doesn't reflect who actually created the transaction as Workstation ID's
change everytime a user signs onto the system.  We have transactions being
entered both through IM and PMC and this has become a big issue.  I'm hoping
one or more of you have run into this same issue and found a way to resolve
it without it being a huge headache.

Any help or guidance is appreciated.

Thanks,
Paola Groeber
MAPICS Consultant
Goodman Manufacturing Company
Houston, TX


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.