Re: MCH4227 while saving in SEU?

On 26-Nov-2013 13:08 -0800, David Gibbs wrote:

On 11/26/2013 2:44 PM, rob@xxxxxxxxx wrote:

Perhaps I'm off base here but can't you edit COBOL with STRSEU and
not even have the compiler loaded?

Any source type that is not PLI likely would allow Source Edit Utility (SEU) editing without that error; i.e. the error is almost surely due to its SrcType specification. But of course using a source Type that does not have a syntax-checker defined, is probably better than using one that does; i.e. no need to put up with the errors, nor to turn off the syntax-checking [for changed lines].

All I know is that SEU was ONLY choking on that particular source
member AND the PL/1 compiler is completely borked on that system. I
could see no weird characters in the member.

The first thing the QSULOAD [SEU load member] processing does is effect essentially, an ADDLIBLE QPLI, to get the PL/I compiler code in the path\library-list [as the Product (PRD) library]. Then the PL1 source processor is invoked. This is the same as for the RPGLE source TYPE, but in that case the QDEVTOOLS library is added, and the RPG source processor [e.g. QRNS4SEU] is invoked.

I was able to edit it with RDP though

Maybe it's trying to syntax check the member because it thinks we do
have the PL/1 compiler.

Beyond simply syntax checking the source, there may be some level of effective /compile/ [maybe binder component] activity as well; depends on the HLL processor. The member has an associated-space that many compilers use to store some permanent information about the source level; e.g. to verify that the *source level matches the compiled level. So, the language syntax-checker may invoke some processor, for which legitimately, there may be some /instruction stream/ translation required.

The SQL pre-compiler has its own similar storage, but IIRC storing its information only in the generated pre-compile member, not in the original member.?

If there is something wrong with the member's User-Storage-Area [I can not recall what they were actually called; a sub-section of the member object associated space], and if that is the origin for the problem experienced, then creating a new\empty member into which just the data is copied from the problematic member, the problem not exist in the new member. If so, a DMPSYSOBJ against the member [or less desirable, DMPOBJ of the *FILE and then locate the member in the dump] can be reviewed for the information stored in the old member as compared to the new member. A copy [CPYF or CPYSRCF] or a restore that creates the member rather than merely placing data in the member, will carry-over the MbrUSA of the original member.