Hi
I've not personally tackled this problem before.
Is it possible to execute as part of logon to your pro-iv application a system command (something like ipconfig) on the client pc ... that outputs the results to a text file ... then acess this text file for the IP address.
There are commands CLIENT.Execute, CLIENT.Send, CLIENT.Receive which may be helpful in executing commands and file-handling on client pc.
I'll also chase one of my colleagues who may know more in this area.
Plus have you tried pro-iv support as they are generally helpful with such queries.
Hope this helps
George
- ProIV Resource Centre
- → Viewing Profile: Posts: George Macken
Community Stats
- Group Members
- Active Posts 248
- Profile Views 9,293
- Member Title ProIV Guru
- Age 60 years old
- Birthday January 15, 1965
-
Gender
Male
-
Location
Co. Wicklow, Ireland
Previous Fields
-
First Name
George
-
Surname
Macken
-
Nationality
Irish
-
Year Started ProIV
1987
-
Highest ProIV Version Used
5.0
-
Company Working For
Peritus Solutions Ltd (using PRO-IV)
-
Companies Worked For
FM Systems (FMS) / Allfinanz - 10yrs
MDIS,
AMP Life Ltd (Australia),
All Solutions (West Australia),
Raptors,
Glovia,
DIRECT LINE,
Have worked directly/in-directly for the listed companies -
Extra Notes
also contactable at
+ 353 87 9196546
+ 353 1 2871967
0
Neutral
User Tools
Friends
George Macken hasn't added any friends yet.
Latest Visitors
Posts I've Made
In Topic: how to obtain the ip address in open client?
14 May 2013 - 09:44 AM
In Topic: Rebooting ProIV Server Nightly - Should We?
03 April 2012 - 01:17 PM
Hi Ross
"We have many users who don't log off correctly so restarting the kernel without rebooting is a good idea."
We have also encountered this problem of users not logging off, it was a very regular occurrence when we exposed the system to (wan, stunnel, vpn, etc), we implmented usage @TIMEOUT to log-out users after a period of inactivity and this made a big difference in reducing the occurrences.
Platform win2003, pro-iv 5.5 and oracle 9i, generally servers are not re-booted, occasionally the pro-iv service is stop/started to clear any rogue sessions/users.
Rgds
George
http://www.proivrc.c...h__1#entry19180
"We have many users who don't log off correctly so restarting the kernel without rebooting is a good idea."
We have also encountered this problem of users not logging off, it was a very regular occurrence when we exposed the system to (wan, stunnel, vpn, etc), we implmented usage @TIMEOUT to log-out users after a period of inactivity and this made a big difference in reducing the occurrences.
Platform win2003, pro-iv 5.5 and oracle 9i, generally servers are not re-booted, occasionally the pro-iv service is stop/started to clear any rogue sessions/users.
Rgds
George
http://www.proivrc.c...h__1#entry19180
In Topic: pro-iv record locking question
09 February 2012 - 10:22 AM
Hi
What database are you using ISAM, ORACLE ?
You have described that there is a screen function where a user can change records
AND
an update function that another user/session can delete the same records
The user in the screen is not going to have a good user experience, that records they have selected for processing in a paging screen are deleted at same time by another process/user.
A possible solution (I have used this in past)
re-design the screen function
a) in an update function load the selected keys and maybe some data fields into a workfile
perhaps you could set a value on the data record to show that this record is on-hold/selected for processing
(generally I'd record OPR id and process-function that has selected/held the data record)
use this file as the primary file in your paging screen and the user changes values on this file
c) on exit from the paging screen call an update to apply the changes captured.
Make sure that you remove the value that identifies the record(s) is being processed.
If the update finds that the data record(s) has been deleted (no longer present) then you could present the keys of the missing records on an error report/screen to the user.
you could also re-design the update function
a) read the table fist in Lookup mode and check the value on the data record that identifies if a record has been selected by another process - is lready seleced than DSEL.
Then read the table for a 2nd time in Delete Mode
Hope this helps
Rgds
George
What database are you using ISAM, ORACLE ?
You have described that there is a screen function where a user can change records
AND
an update function that another user/session can delete the same records
The user in the screen is not going to have a good user experience, that records they have selected for processing in a paging screen are deleted at same time by another process/user.
A possible solution (I have used this in past)
re-design the screen function
a) in an update function load the selected keys and maybe some data fields into a workfile
perhaps you could set a value on the data record to show that this record is on-hold/selected for processing
(generally I'd record OPR id and process-function that has selected/held the data record)

c) on exit from the paging screen call an update to apply the changes captured.
Make sure that you remove the value that identifies the record(s) is being processed.
If the update finds that the data record(s) has been deleted (no longer present) then you could present the keys of the missing records on an error report/screen to the user.
you could also re-design the update function
a) read the table fist in Lookup mode and check the value on the data record that identifies if a record has been selected by another process - is lready seleced than DSEL.
Then read the table for a 2nd time in Delete Mode
Hope this helps
Rgds
George
In Topic: Oracle Selection Issue
21 December 2011 - 09:34 AM
Hi Tom
Reports in Pro-IV are not my main area of expertise - but I've wrote a lot of them
In your report - if you rem out the sel-only in LS of ORDER_DTL does the report execute and return the all detail lines from the DTL table - place UMSG in the After REad of the DTL. ?
Assumin the report is to print 1 order only, I would typically code it as
LS1 (Assuming you are reading the HDR in this LS)
defined as ONE-TIME = 'Y'
LS1 - Default LGC
ORDER_HDR_ID = some value passed into the report function
LS2 (Assuming you are reading the DTL in this LS)
defined as ONE-TIME = 'N'
LS2 - Default LGC
* ORDER_HDR_ID this value inherited from LS1
ORDER_HDR_LINE = ''
SEL-ONLY( ORDER_HDR_ID )
The FLDs of LS1 should encompass the fields of LS2
If you post attachements/prints of your functions and the 2 Filedefs then I'm sure one of the many contributors to this forum will help you out.
Hope this helps
Rgds
George
Reports in Pro-IV are not my main area of expertise - but I've wrote a lot of them
In your report - if you rem out the sel-only in LS of ORDER_DTL does the report execute and return the all detail lines from the DTL table - place UMSG in the After REad of the DTL. ?
Assumin the report is to print 1 order only, I would typically code it as
LS1 (Assuming you are reading the HDR in this LS)
defined as ONE-TIME = 'Y'
LS1 - Default LGC
ORDER_HDR_ID = some value passed into the report function
LS2 (Assuming you are reading the DTL in this LS)
defined as ONE-TIME = 'N'
LS2 - Default LGC
* ORDER_HDR_ID this value inherited from LS1
ORDER_HDR_LINE = ''
SEL-ONLY( ORDER_HDR_ID )
The FLDs of LS1 should encompass the fields of LS2
If you post attachements/prints of your functions and the 2 Filedefs then I'm sure one of the many contributors to this forum will help you out.
Hope this helps
Rgds
George
In Topic: RECORD LENGTH REDUCED
12 October 2011 - 08:16 AM
Hi Rob
The following is the procedures that we follow if we encounter the RECORD LENGTH REDUCED in @F ....
a) run ischk filename.pro to check the integrity of the file.
Run iskeys filename.pro > FILENAME.TXT, in the header output is the "record length: nnnn".
If your record length is not 3000 (not > 1583 for your file), then apply the following
c) run "isout filename.seq filename.pro" creating seq file of the existing .pro file
d) run iscr -knn -r3000 to create the file with rec len of 3000
(record lenght is now > 1583 and will accomodate popualtion to max of all fields and allow for addition of more fields)
e) run isin filename.seq to re-populate the file with its original contents.
f) run ischk filename.pro to check the integrity of the file.
hope this helps
George
The following is the procedures that we follow if we encounter the RECORD LENGTH REDUCED in @F ....
a) run ischk filename.pro to check the integrity of the file.

If your record length is not 3000 (not > 1583 for your file), then apply the following
c) run "isout filename.seq filename.pro" creating seq file of the existing .pro file
d) run iscr -knn -r3000 to create the file with rec len of 3000
(record lenght is now > 1583 and will accomodate popualtion to max of all fields and allow for addition of more fields)
e) run isin filename.seq to re-populate the file with its original contents.
f) run ischk filename.pro to check the integrity of the file.
hope this helps
George
- ProIV Resource Centre
- → Viewing Profile: Posts: George Macken
- Privacy Policy