GRID PARALLEL PROCESSING PROBLEM

[Krohn]

Hello,

PROBLEM:

in the first execution only, occurs the following:

The jobs do execute in parallel but they get the same LSF ID, in the same machine.

If execute it again, then it goes ok:

The jobs also will run in parallel but with different LSF ID (the correct way) and random machines.

PROBABLY CAUSE

NOTE: Accessing the SAS Metadata Repository produced: ERROR: No terminal connected to the SAS session.

NOTE: Retrieving login information based on AuthenticationDomain from the SAS Metadata Server failed.

NOTE: SAS application server not found; the local machine will be used.

CODE:

%LET RC=%SYSFUNC(GRDSVC_ENABLE(_ALL_, RESOURCE=SASApp));

options autosignon ;

RSUBMIT S1 WAIT=NO;

%put Remote S1 SO ID: &sysjobid. ;

%put Remote S1 LSF ID: %sysget(LSB_JOBID);

ENDRSUBMIT;

RSUBMIT S2 WAIT=NO;

%put Remote S2 SO ID: &sysjobid. ;

%put Remote S2 LSF ID: %sysget(LSB_JOBID);

ENDRSUBMIT;

%put Main Session SO ID: &sysjobid. ;

%put Main Session LSF ID: %sysget(LSB_JOBID);

MAIN LOG:

NOTE: Connecting to SAS Metadata Server produced: WARNING: No logins found.

NOTE: Accessing the SAS Metadata Repository produced: ERROR: No terminal connected to the SAS session.

NOTE: Retrieving login information based on AuthenticationDomain from the SAS Metadata Server failed.

NOTE: SAS application server not found; the local machine will be used.

Main Session SO ID: 20889

Main Session LSF ID: 325069

Remote S1 SO ID: 28418

Remote S1 LSF ID: 325069

Remote S2 SO ID: 25121

Remote S2 LSF ID: 325069

[ChrisNZ]

@ChrisHemedinger This is the third unanswered grid-related question in a month. Should we create a grid community?

[Krohn]

UP

[JuanS_OCS]

@ChrisNZ rather than that, perhaps something to move to the Administration Community.

Do you have the rights for the move? Otherwise, i can.

[ChrisNZ]

@JuanS_OCS 

This is not really an admin question. But there is nothing to lose moving it, it seems, as no answer is forthcoming. 

Data management seems to get questions about connections. I'll let you move it. 🙂

@ChrisHemedinger 

Do you think a grid community would be useful?

The downside of course is that question end up isolated in a smaller specific community, but Grid users seem to struggle getting answers.

[ChrisHemedinger]

Moved this to the Admin community -- that tends to be where the grid expertise is.  @ChrisNZ, re: a dedicated grid community -- if we saw more grid-specific discussion, I'd support that.  But most grid users ask questions in the context of other problems, so I think it might hurt us if we tried to specialize too much.

[JuanS_OCS]

Thank you @ChrisHemedinger. I fully agree with all your comments.

@ChrisNZ, actually, I do believe it is an admin question. I will explain below. But basically, if it is not related to code, to configuration of the SAS system (even if it is functional configuration), and I think this one could be one of those, I always recommend to bring it to the SASAdmins attention, especially if no one else is answering the question in the originally selected public.

@Krohn,

I think our focus should go to this message:

NOTE: Retrieving login information based on AuthenticationDomain from the SAS Metadata Server failed.

Your challenge here is to talk you your SAS Admin and ensure that, the account that actually runs the job and connects to the SAS metadata, can log in to the metadata and it is a user name.

I see often one of these cases (see in SAS Management Console or Active Directory):

• the account is an account for a group. If this is the case, it is an account that cannot read metadata, per-se, because it cannot log in to metadata, it is used for outbound connections (to databases, to platform manager, etc)
• The account is locked
• The password set in SMC is outdated or mis-typed
• The user account is not linked to the right group anymore
• if you have a options statement to connect to the metadata, say, before or in the signon statement, you can always check if you could connect, actually, to the metadata with that account.

The easiest answer would be that, probably, someone has changed user/group definitions recently in SAS Management Console or Active Directory/LDAP. If those changes can be rolled back, the problem should be solved.

And if not, and cannot find the exact cause, perhaps you might need support from SAS Technical Support or even a SAS Consultant.

For the time being, please let us know how it goes, we will try to help.