Jump to content


JC Jones

Member Since 09 Jul 2008
Offline Last Active Oct 12 2009 10:49 PM
-----

Topics I've Started

V5 /bin/sh workaround on Fedora

09 October 2009 - 11:05 PM

PROIV Version 5.0 (Green Screen)
Currently on Red Hat 7.3

Looking at migrating from Red Hat 7.3 to Fedora 10. Already worked around the obvious libc and libm issues by creating a compatible environment using the LD_LIBRARY_PATH environment variable and setting up older versions of of the needed libraries (libm-2.2.5, libc-2.2.5, and ld-2.2.5). Also fixed the same problem with Iscollect by instructing it to run in the alternate compatible libraries environment. The application runs but displays errors sporratically when attempting to use /bin/sh. Obviously I can't change the /bin/sh symlink to an older version so I tried making /bin/sh a script that looked for PROIV only set environment variables and did an exec to an older version of sh that is compatible with the 2.2.5 libraries. That got rid of the errors in PROIV but still cannot print (everything else seems to work fine). However, the system will not boot without /bin/sh being a direct symlink to /bin/bash which requires the 2.9 libraries. Kind of a catch 22. Had to boot from a live CD and restore /bin/sh to the symlink directly to /bin/bash to get the system to boot again.

Does anybody have any ideas how to work around this issue. I cannot find anywhere in the PRO-IV config where I can tell it to use a different path for sh, /bin/sh appears to be hardcoded somewhere in the binaries but I could not find that string anywhere in the pro binary.

Also, if anybody has any idea why it might not be printing either using lp or lpr (I've tried updating PROIV to use lpr -P which does work from the command line even when using the compatible environment).

Thanks,
JC Jones

SEL-XXXX problem

10 July 2008 - 05:37 PM

Version 5.0, green screen, RH Linux OS

We have a problem selecting records from a PRO-ISAM file using SEL-(ANYTHING) when not assigning all keys for a single specific record select. The file has 4 keys, and if we assign all 4 keys and use SEL-ONLY the single record is retrieved fine. We need to retrieve all records with only the first 2 keys matching but for some reason with this particular file we get no reads at all when only the first two keys are defined before the SEL-XXXX statment.

The following examples are in an update function with 3 LU's, the first 2 LU's are getting the information needed from other files needed to access (and subsequently filter the retrieved records) from this file. Everything works perfectly until the 3rd LU retrieves no records unless it's forced to retrieve a single specific record. The following code is in the Default Logic for the 3rd LU.

For example:
This works perfectly and retrieves the specific record requested:
IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "002"
IM.TFLAG = ""
SEL-ONLY(IM.TFLAG)

Any of the following retrieve absolutely no records (no after read logic hit):
IM.TTYPE = "S"
IM.ITREF = " 250192"
SEL-ONLY(IM.ITREF)

IM.TTYPE = "S"
IM.ITREF = " 250192"
SEL-PARTIAL(IM.ITREF)

IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "0"
SEL-ONLY(IM.ITSEQ)

IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "001"
IM.TFLAG = ""
$END_KEY = @COMP + IM.TTYPE + IM.ITREF + "999"
SEL-RANGE($END_KEY)

This is the only file that has this problem, we use the set one or more keys and use SEL-ONLY on the last key set all the time and never have any problems.

The definition of the file is attached - any ideas as to what the problem with this file may be?

We have checked the file for corruption and it's clean, we've checked the file for size limit and and it's well within the defined file size.

Thanks,
JC Jones