Robelle Tech:Tips on C, Security

April 2003

Boosting your e3000 productivity

Tips on C, Security

Solving a Weird C Compile Error

By Barry Lake
Allegro Consultants

We recently resolved a support issue in which a customer was having trouble compiling a C program within Qedit for MPE, and believed that Robelle software was at fault. The error in question was:

line 1438: error 1615: Default
parameter specification not supported.
The offending line of code was:

fnum = FOPEN ( fname, fop, aop,
-recsize,,,,,, filesize );

We’ve frequently done similar things in our own C programs, so we know this should work, and we often do compiles inside Qedit, as well, so we were fairly certain the problem didn’t have anything to do with Qedit. For the most part Qedit simply passes non-Qedit commands to MPE for execution. But just to be sure, our first troubleshooting tactic was to have the customer try the same compile command from the MPE prompt. As expected, he got the same error, which ruled out Qedit as the culprit.

Next, we asked to see the contents of the customer’s CCXL command file. In particular we wanted to see exactly how the C compiler was invoked. Here’s what we found:

RUN CCOMXL.PUB.SYS; INFO=”!INFO”;
PARM=!_CCPARM_;
XL=”QCOMPXL.PUB.ROBELLE”

The XL parameter showed that the compiler had been “Qedified.” (QCOMPXL allows programs which reference it to understand Qedit workfiles.) As before, we didn’t think QCOMPXL could have anything to do with the problem. In fact, tests showed that the problem existed regardless the format of the file, flat ASCII or Qedit. Even so, to be thorough, we asked the customer to run his compile without the extra XL parameter. Same result, same error, which ruled out QCOMPXL as the source of the problem.

Thus we had determined definitively that no Robelle software was involved in causing the customer’s problem. Although we had suspected this from the start, it was nice to get verification of it. Nevertheless, as is our wont, we continued to work with the customer, even though this was technically no longer our issue.

We next turned our attention to source code and environmental factors. We know that the C language does not support default parameters. But we also know that in HP’s implementation default parameters are supported, at least for system intrinsic calls, via the “#pragma intrinsic” declaration mechanism. So we asked the customer if he had included “#pragma intrinsic FOPEN” in his source file. This line of inquiry bore no fruit, however, as the customer assured us that he had included the correct pragma in his source. In addition, in our tests we found that omitting the appropriate pragma statement from our source code resulted in a different compiler error message from what the customer was seeing:

line 28: error 1634: Missing arguments only allowed
on intrinsic calls.

We then asked the customer for the exact command he was using to perform his compile:

ccxl mysource, myobject,
*lp; “-Aa -C -Wc,-m,-o,-w2”

That looked reasonable enough, but when we explicitly used the customer’s info string in our own test compilation, we were finally able to reproduce the same error he was seeing!

Thus we knew that something about the options in the info string was causing a problem, but which option? From reading the compiler options section of the HP C/iX manuaI it appeared that the customer’s info string was perfectly valid. So we needed to compare it with something we knew worked.

In our development environment we had long ago configured the appropriate default info string in a CI variable that gets set up at login time, and is used in all C compilations. Since everything had been working for us for so long we simply forgot about the info string. When we compared our default info string “-Aa +e -DMPEIX -Wc,-w1” with the customer’s info string, we saw several obvious differences.

What turned out to be the crucial difference is that our info string includes the “+e” argument to the “-A” option. The C/iX manual describes that argument thusly:

“Allows the use of extension features, such as long pointers and using the $ character in the identifier name.”

Apparently, extension features also include support for inserting default parameters, although this isn’t explicitly documented. At any rate, once our customer added “+e” to his info string, all compilations worked without error. Problem solved!

The bottom line is that two things must be true in order for C/iX compilations to support default parameters in MPE intrinsic calls:

1) The intrinsics must be declared via the “#pragma intrinsic” mechanism
2) The info string passed to the compiler must include the “+e” option, which enables the use of extension features.

FTP Passwords with Vesoft’s Security/3000

By François Desrochers

I ran into a problem accessing our HP 3000 with ftp. It kept on rejecting the connection request. More specifically, it was rejecting the login information.

c:\>ftp my3000
Connected to my3000.robelle.com.
220 HP ARPA FTP Server [A0011001] (C) Hewlett-Packard Co. 1990
User (my3000.robelle.com:(none)): francois/longpassword,user.account
530 User log on unsuccessful
Login failed.

I was able to connect using other protocols like telnet and NS/VT. After a number of tries monitoring the logon process, I realized that something was wrong with my password.

We use the session password feature of VESoft’s Security/3000. One of the clues was in Security/3000’s logfile. Whenever I entered an invalid password, I could see:

FTP :HELLO FRANCOIS,USER.ACCOUNT : BAD PASSWORD
13:44/142/AIF:PE CHLOGON: Refused chlogon
FRANCOIS,USER.ACCOUNT: BAD PASSWORD

Whenever I entered my password, the login request was rejected, but nothing was logged. The request was apparently not getting to Security/3000. I changed my password to a temporary 3-character password and was able to use ftp. The logfile then showed:

FTP :HELLO FRANCOIS,USER.ACCOUNT : OK
13:46/142/AIF:PE CHLOGON: Allowed chlogon
FRANCOIS,USER.ACCOUNT: CHECK ok

As I tried to set my password back to its original value, I realized that it had 9 characters. I set it to the first 8 characters and everything worked from that point.

Login requests have to go through the ftp server and MPE’s AIF:PE before getting to Security/3000. I suspect that either ftp server or AIF:PE truncates the password to 8 characters before passing it to Security/3000.

We didn’t have any password edit mask in Security/3000. I was not able to find the default maximum length but, just for fun, I have been able to enter an 80-character password. So, how do you define a password maximum length?

Enter a $VEPASS-FORBID directive similar to this one in the securcon file:

$VEPASS-FORBID “len(p)>8” “Password must have
1-8 characters” francois,@.@

The first string is the condition that you want to check. “LEN” is a Security/3000 function which returns the length of the variable enclosed in parentheses. “p” is the internal variable name for the password itself. The second string is a message to be displayed if the condition is true. The last piece of information is optional. If not specified, the condition is checked for all users. In the example above, it is only checked when the session name is “francois.” As with all VESoft software, $VEPASS-FORBID directives are flexible and can do almost anything you need.